iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 29
0
新手入門,如有錯誤,歡迎指正~~~

系列文章同步更新於部落格

在整個 RTCPeerConnection 建立連線的步驟中,如果要到正式環境使用的話,必定會遇到網路(NAT)的問題,也就是在進行 SDP offer/answer 前,必須先透過 ICE 選取到適合的 candidate 後才能開始進行的原因。

其 ICE 查找到時確定能連接時 RTCPeerConnection.iceGatheringState 屬性就會轉為 complete,接續進行 SDP offer/answer 的步驟。

WebRTC 就是透過 ICE 來處理實際網路(NAT)的複雜性。

而網路上有許多文章都講得不錯,在這裡只統整主要用途與參考的資料。

ICE

為了解決NAT的複雜性,ICE 將會嘗試找到連接對方的最佳途徑。

而再進行查詢時的會有幾個步驟:

  1. ICE agent 在操作系統中查詢本地 IP 地址。
  2. 失敗的話,則 ICE agent 會查詢外部 STUN 服務器 以檢索對等方的 public IP 和端口。
  3. 再失敗的話,則 ICE agent 會將 TURN 服務器 做為最後的選擇。如果對等連接失敗,則數據將通過指定的中介進行中繼。

換句話說:

  • STUN server 是用来獲取外部地址的。
  • TURN server 是用來在直接連接(p2p)失敗的情況下進行中繼數據流量的。(相對的這樣其實就不算是p2p了,中間還是要透過中繼server幫我們傳遞數據。)

在使用上,ICE server 的 URL 加進 RTCPeerConnection 參數中(如下):

const ice = {
  "iceServers": [
    {"url": "stun:stun.l.google.com:19302"},
    // {"url": "turn:turnserver.com", "username": "user", "credential": "pass"} //範例
  ]
};

const peer = new RTCPeerConnection(ice);

範例是使用 google 提供的公用STUN server,而turn server的話google也有提供open source project: coturn 可以參考看看~

為了解決 NAT 的複雜性(如下):

https://ithelp.ithome.com.tw/upload/images/20201012/20129521QZQBw6qRoO.png
擷取自MDN

很好地呈現了,最終經過 ICE 處理後的樣貌。

總結

上述是了解一下ICE(STUN/TURN)的作用,方便實作上遇到問題時能夠找到問題點做更深入的研究,
網上蠻多資源再說明ICE(STUN/TURN)相關可供參考:

參考


上一篇
[實作篇]WebRTC - Video Chat (data channel)
下一篇
WebRTC之旅:終
系列文
菜雞前端邁入網頁即時通訊(WebRTC)之旅30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言